home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000824_dsr@hplb.hpl.hp.com _Wed Apr 7 13:58:25 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Return-Path: <dsr@hplb.hpl.hp.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA29264; Wed, 7 Apr 93 13:58:25 MET DST
  4. Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA06038; Wed, 7 Apr 1993 14:17:37 +0200
  6. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 7 Apr 93 13:11:46 +0100
  7. Received: by manuel.hpl.hp.com
  8.     (16.6/15.6+ISC) id AA25570; Wed, 7 Apr 93 13:18:39 +0100
  9. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  10. Message-Id: <9304071218.AA25570@manuel.hpl.hp.com>
  11. Subject: Re  VT100 etc...
  12. To: timbl@nxoc01.cern.ch
  13. Date: Wed, 7 Apr 93 13:18:37 BST
  14. Cc: www-talk@nxoc01.cern.ch
  15. Mailer: Elm [revision: 66.36.1.1]
  16.  
  17. In  <9304061951.AA17526@ nxoc01.cern.ch > Tim makes the case for
  18. WWW browsers that work effectively over phone lines.
  19.  
  20. It also seems to me that we should revisit the specs for HTRQ and
  21. the HTTP Mime headers to boost network performance via compression.
  22.  
  23. Tim says:
  24.  
  25. > The requirements or the phone line protocol are that
  26. > it should be efficient, it should allow long transfers
  27. > to be stopped at short notice to make way for new ones,
  28. > and it should, preferably, look ahead to guess what the
  29. > user might want next, and transfer it while he is reading
  30. > what he has got.   This would take advantage of a reasonable
  31. > amount of cache disk space on the user's machine, if he has
  32. > it.  The ideal is to keep the phone line humming as it is
  33. > the bottleneck. The user browses around, with an apparently
  34. > very good response time. All the scrolling and such is done
  35. > locally so that is instant.
  36.  
  37. > There is not as far as I know any existing public protocol
  38. > which does this.   If anyone knows of one, please say!
  39. > If anyone wants to [form a group to] define and implement
  40. > one, then why not.  I see this as an important step
  41. > toward getting the internet information world out to
  42. > everyone in schools and homes.
  43.  
  44. Are you familiar with the standard for Compressed TCP/IP Headers for
  45. Low-Speed Serial Links, RFC1144? This cuts the headers down to an
  46. average of 3 bytes and is both efficient and simple to implement
  47. (about 250 lines of C). It was motivated by the need to get good
  48. response times when using telnet over phone lines running from
  49. 300 to 19,200 bps. It is designed to increase line efficiency
  50. while offering an under 200 millisecond response time for character
  51. echo. For a 9600 bps line there is no point in increasing packet size
  52. longer than 200 bytes. Increasing the maximum packet size to 576 bytes
  53. increases the average delay by 188% while throughput increases by 3%.
  54.  
  55. The complete Berkely Unix implementation of cslip is available by
  56. anonymous ftp from ftp.ee.lbl.gov as "cslip.tar.Z". I expect versions are
  57. also available from PC software vendors, e.g. Distinct of Saratoga CA who
  58. can be contacted at mktg@distinct.com (if not we should press them to
  59. implement cslip right away!). Smart IP implementations also open and close
  60. the phone line intelligently - so you don't hang onto an expensive long
  61. distance line a moment longer than you need to.
  62.  
  63. The next step is to devise a www browser which offers look-ahead (under
  64. user control via a preferences menu of course!). This would need to take
  65. into account available resources (disk, memory, line costs) to decide which
  66. references to prefetch. I, for one, would hate the browser to prefetch
  67. megabytes of postscript and jpeg files! This shows the need to check file
  68. size first using the appropriate methods, and underlines the need for
  69. HTTP2 servers to supply a Length: field with document headers.
  70.  
  71. Finally www servers should offer compressed versions of documents. I have
  72. looked through the MIME spec and the appropriate thing seems to be:
  73.  
  74.  a) documents are returned with an attribute specifying the kind
  75.     of compression
  76.  
  77.         Content-Type: text/html; compression=Z
  78.         Content-Transfer-Encoding: 8BIT
  79.  
  80.  b) Browsers can request compression with the HTRQ field
  81.  
  82.         Accept-Encoding: compression=Z
  83.  
  84. Where "Z" stands for the standard compress/uncompress utilities.
  85. Some alternatives could be "z" for gzip, and "lzh", "zip" for the PC.
  86.  
  87. What do you think?
  88.  
  89. Dave Raggett